home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9225 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.2 KB  |  47 lines

  1. Newsgroups: comp.dcom.modems
  2. Path: news.uunet.ca!gts!bokonon!stephen
  3. From: stephen@bokonon.ussinc.com (Stephen M. Dunn)
  4. Subject: Re: How come Z-Modem is faster than X-Modem?
  5. Organization: United System Solutions Inc.
  6. Date: Tue, 26 Mar 1996 03:36:32 GMT
  7. Message-ID: <DouvCw.ME@bokonon.ussinc.com>
  8. References: <4inro0$9mj@alcor.usc.edu> <1996Mar21.110405.6710@ms.philips.nl>
  9.  
  10. In article <1996Mar21.110405.6710@ms.philips.nl> Pvestjen@ms.philips.nl (Patrick Vestjens) writes:
  11. $Abu Wawda (wawda@alcor.usc.edu) wrote:
  12. $: I have the specs for the X-modem protocol and I see that it doesn't
  13. $: add much overhead, just 4 bytes per 128 byte packet. So how come
  14. $: Z-modem is so much faster? (Unfortunately, I haven't found the specs
  15. $: for Z-Modem yet.) Does it do compression? Thanks,
  16. $
  17. $As far as I know Zmodem is a streaming protocol while Xmodem is not.
  18.  
  19.    Correct.
  20.  
  21. $This means that when using Xmodem the sender requires an acknowledgement
  22. $from the receiver after each block. In the mean time it just waits and
  23. $that costs a lot of time.
  24.  
  25.    This is particularly true in the case of a high-latency connection,
  26. such as when an error correction protocol is in use.  LAP-M and MNP
  27. both cut up the data flow into packets, and until the receiving modem
  28. has received and verified an entire packet, it doesn't start sending
  29. that data to the computer.  The computer, in turn, can't verify
  30. the contents of the Xmodem packet until it's all been received,
  31. and so there are additional delays present.
  32.  
  33. $Zmodem does not require an acknowledgement after each block. I think it
  34. $only sends one if an exception occurred. See the sender just keeps on
  35. $sending and sending and sending ...
  36.  
  37.    It can run in streaming mode or in sliding window mode, in which
  38. there's an outstanding window of some size and an ack must be sent
  39. at some point during reception of each window size.  Assuming that
  40. the window size is high enough that the acks get back in time,
  41. the sliding window mode will effectively stream anyway.
  42. -- 
  43. stephen@bokonon.ussinc.com               ...!{xrtll,gts.org}!bokonon!stephen
  44. ----------------------------------------------------------------------------
  45. Stephen M. Dunn, CNE, ACE, Sr. Systems Analyst, United System Solutions Inc.
  46. 104 Carnforth Road, Toronto, ON, Canada M4A 2K7          (416) 750-7946 x251
  47.